-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: webauthn (passkey) support #149
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
Ok, I have implemented the changes I proposed. I'm a lot more satisfied with how it looks now. |
Change useServerSession() to useUserSession()
* refactor: request token * chore: fix import * up * up * Merge branch 'main' into refactor/request-token * [autofix.ci] apply automated fixes * chore: fix types issue * chore: lint --------- Co-authored-by: Sébastien Chopin <[email protected]> Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
* feat: add tiktok provider * docs: add tiktok * feat: add tiktok .env example * chore: remove console logs * [autofix.ci] apply automated fixes * chore: remove unused authorizationParams * chore: use new utils * fix: extends from RequestAccesTokenBody interface * [autofix.ci] apply automated fixes --------- Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
commit: |
I was experimenting with this and I've noticed that regardless if registration's Is this correct? Should I open up an issue? |
Yes, the credential creation was successful. That's why the |
resolves #119
This makes use of the
@simplewebauthn
packages documented hereIt is open source but doesn't accept contributions. The maintainers are actively trying to support new runtimes which is exactly what we need for the Nuxt ecosystem
I based the interface on the
oauth
event handlers already present in this package.By default the challenge is stored in an encrypted cookie because it is not known beforehand what kind of storage is available. In secure connections this works but for better security guarantees the developer can choose to store the challenge server side. (I'd say highly recommended)
A
getOptions
function where the developer can customize the respective options as much as they want. This allows for multiple webauthn implementations in a single project (for example one for passkeys and one for standard physical keys like Yubikey with more strict requirements)There is a guide for FIDO conformance here https://simplewebauthn.dev/docs/advanced/fido-conformance (not sure if fully possible with my current implementation)
On the frontend it is as simple as: